III. Overview of the *B 17 00 

The B1700 is a small, general-purpose computer (Burroughs, 1972b) that 
is particularly wellsuited for interpretation and emulation. The 
features of the B1700 that make it unique and unprecedented are: 

1) Dynamically alterable, vertical microprogramming 

2) Bit addressable main memory 

3) Dynamic control of functional width of processor registers 
and busses 

4) Dynamic control of memory access width 

5) Microprogram subroutine capability 

6) Stack structure 

(For a more detailed, discussion of the B1700, see Wilner, 1972a). 

Principles f irst. espoused in the Burroughs B5500 (Burroughs, 1969b) 
and in the Burroughs B35Q0. (Burroughs, 1969d) have culminated in the 
B1700. The B5500 is designed to process ALGOL, while the B3500 is a 
COBOL machine. Both of these machines have their designs hard-wired 
into them. The B1700, however, is "soft" at the level that the others 
are "hard". This, combined with a micro-order designed for interpreter 
writing, combined with the attributes listed above, have produced a 
machine that is singular in its capacities. 

The virtual machines which have been produced for the B1700, including 
the SDL machine, are an order of magnitude more powerful at what they 
do than are hard-wired systems. Programs represented in these soft 
machine languages are from 25% to 75% smaller than on byte-oriented systems, 



IV. The SDL Machine 

The SDL language was designed to be used for implementation of the MCP 
• and for implementation of the different compilers. In conjunction with 
the design of the language, was the design of a "machine" that would 
"execute" the statements of the language. 

The SDL machine is a conglomeration of the ideas of many people. 
Particularly included are the language-directed design ideas of 
McKeeman (McKeeman, 1967), the stack and display mechanism of Randell 
and Russell (Randell, 1964), and the design of the Burroughs B6700 
(see Hauck, 1968). See also Burroughs, 1969b and Burroughs, 1969c. 
The original SDL machine was designed by G. Brevier and B. Rappaport 
b'f Burroughs Corporation. Later additions and modifications to the 
basic machine design included ideas of C. Kaekel and the author, as 
well as other employees. of Burroughs Corporation. 

This section will describe the resulting S-machine and S-language. 



A. Stack Mechanism 

A B1700 program consists of code segments scattered in memory, one 
block of data bounded by a Base Register and a Limit Register, .and a 
contiguous, read-only block (the Run Structure) containing program 
attributes. Also scattered throughout memory, in addition to code seg- 
ments, are file attribute blocks and segment dictionaries. The area 
inside Base-Limit is divided into two parts: a static part and a 
dynamic part. In the case of an SDL program, the static area contains 
the S-machine stacks and the dynamic area contains paged array page 
tables and paged array pages (see Figure 1). 

The SDL machine stack structure originally evolved from Randell and 
Russell (see Randell, 1964) and from the B6700 (see Hauck, 1968). This 
scheme has proved to be. clean and easy to implement, and has resulted 
in a relatively small amount of code in the interpreter for stack 
management. 

The structure " . of the S-machine stacks is shown in Figure 2a. 
The inter-relationships among the stacks are shown in Figure 2b. 
The Name Stack and the Program Pointer Stack run toward the Base Reg- 
ister (toward low memory, addresses) ; the others run toward the Limit 
Register (high memory addresses). The stacks are used as follows: 

1) Program Pointer Stack: This is a 32-bit wide stack that holds 
code addresses. Entries are pushed onto this stack upon pro- 
cedure or DO group entrance, and are popped off upon procedure 
or DO group exit. 

2) Control Stack: This is a 48-bit wide stack which maintains 



the dynamic history of the allocation of data items. Entries 
are pushed onto this stack upon entrance to procedures with 
parameters and/or local data, and are popped off upon exit 
from these procedures. 

3) Name Stack: This is a 48-bit wide stack that holds data des- 
criptors. The data descriptors may contain values (self-relative) 
or the address of the values (in the Value Stack). Each lexic 
level's data descriptors occupy a contiguous block of entries 

in the Name Stack. • 

4) Value Stack: The Value Stack is a variable width stack which 
contains values of currently allocated (non self-relative) 
data items, as well as the values of temporary data items 
(i.e., intermediate values of expressions). 

5) Evaluation Stack: The Evaluation Stack is a 48-bit wide stack 
which contains data descriptors for intermediate results and 
for temporary storage of procedure actual parameters. 

6) Display: Display is a 32-bit wide array, the entries of which 
contain the addresses of the blocks of data allocated by the 
currently active lexic levels. The addresses' in Display point 
into the Name Stack. A lexic level number is used to sub- 
script into Display. In other words, Display points to all 
the groups of descriptors that can be currently addressed. 



B. Opcode Structure 

Because of SDL's stack structure and segmentation,, code and data addresses 
are short, making the number of bits devoted to opcodes quite signifi- 
cant. In fact, more bits are used for opcode representation than for 
any other purpose, amounting to over one- third of a program's code space. 
Consequently, it was essential that not only should opcodes be represented 
in as compact manner as possible, but also that decode time for opcodes 
should be minimal. 

The SDL S-operators use an encoding based on static frequence of occur- 
rence. Operators are 4,6, or 10 bits in length with the most frequently 
occurring operators requiring the smaller number of bits. 

The first 10 of the 4-bit codes (0... through 9, fi ) represent operators. 
The next 5 are escape codes which indicate that the next 2 bits are to 
be examined in order to determine which operator is to be used. The 
last 4-bit code (Fw) is an escape code which indicates that the next 
6 bits are to be used in order to determine which operator is to be 
used (see Figure 3). 

Originally, the SDL S-operators were encoded using a 3-bit, 9-bit code. 
After a fairly large amount of working SDL code had been generated 
(in the MCP and' the compilers) an analysis was done (on a static basis) 
of the operators used in that code in an attempt to verify that the proper 
encoding had been chosen, or, alternatively, to empirically arrive at 
one that would be optimal. 



If Huffman's algorithm for minimum^ redundancy codes (see Huffman, 1952) 
had been used for SDL opcodes, the space requirements would have been 
minimal, but the time for decoding would have been large. A fixed 
field size would have minimized decoding time but would have required 
a large amount of storage. Using the opcode frequence obtained from 
the analysis mentioned above, an encoding was obtained that was very 
near the Huffman encoding in space required, but still small in decoding 
time (see Figure 4a, b). 

Appendix I contains the SDL S-operators, along with their arguments and 
sizes. It is, perhaps, interesting to note that: 

1) The operator associated with IF-THEN (IFTH) is a 4-bit operator 
while the operator associated with IF-THEN-ELSE (IFEL) is a 
6-bit operator . 

2) All types of literals are used frequently enough to warrant 
4-bit operators (ZOT, ONE, LITN, LIT) 

3) Load Address (LA) is a 4-bit operator while Load Value (L) is 
a 6-bit operator. This result indicates (because of the way 
that the SDL expression code generator generates code) that 
there are more "simple" expressions than "complex" ones. 

4) The operator (UNDO) for DO group and simple procedure exits 
is a 4-bit operator 

5) Comparison for equal (EQL) and unequal (NEQ) are more frequently 
used than the other comparison operators (LSS, LEQ, GTR, GEQ) 

For further description of B1700 memory utilization, see Wilner, 1972b. 



C. Descriptor Formats 

Each SDL data item is represented by a descriptor which specifies the 

attributes of that data item. The data attributes are thus contained 

in the data area, rather than being imbedded in the code. The implications 

of this are that there tend to be fewer instructions (for example, there 

is one add instruction for all possible types — including mixed types — 

rather than a bit add, a character add, a fixed add, etc.) and that the 

instructions tend to be more compact since they reference descriptors 

for attributes , rather than contain the attributes themselves. 

Descriptors in SDL are of two types: simple variables and arrays (vari- 
ables to be subscripted). Simple descriptors are 48 bits in length 
while array descriptors are 96 bits in length. (See Figure 5.) 

Simple descriptors have a type field (discussed below), a length field, 
and a field which contains the data (if the data is not more than 24 
bits in "length and is not In a structure),' or the address of the data 
(if the data is more than 24 bits in length or is in a structure). 

Array descriptors have a type field, a field giving the length of each 
element, a field giving the address of the first element, a field giving 
the number of bits to truncate from the right of a subscript to obtain 
the page subscript (paged arrays only), a field giving the length 
between elements (this is equal to the length of the element on the 
lowest level only of a structured array), and a field giving the number 
of elements in the array. 



The bits in the type field (see Figure 5) are used as follows: 
Bit Use 

1 if the value has been loaded to the top of the Value 
Stack (used when the descriptor is on the Evaluation 
Stack only); otherwise 

1 1 if descriptor is non self-relative; otherwise (data 
item is in address field) 

2 1 if array descriptor; if simple descriptor 

3 1 if length of element equals length between elements; 
otherwise (arrays only) 

4,5 Data type; BIT (00), FIXED (01), CHARACTER (10), 
VARYING (11) (formal descriptors only) 

6 1 if paged array; otherwise (arrays only) 

7 1 if length varying (formal descriptors only) 

It should be pointed out that the use of descriptors along with the bit- 
addressability of the B1700 allows a greater variety of data represent- 
ations, so that the extra bits are more than made up for by not having 
to use "unnatural" representations (a byte for a one-bit flag, for 
example). 



D. Code Addressing ' 

All code on the B1700 is not only re-entrant, but also automatically- 
relocatable, since code addressing is done-through code pointers- 
segment Dictionary entries), rather than 'with memory addresses (this 
is necessary for re-entrancy when the code is overlayab 1 ,s, but not 
sufficient: see IV-E, Data Addressing). The MCP and compilers tend 
to be large programs and, hence, have a large number of segments since 
the segments themselves must be small (due to the memory restrictions 
of the B1700). In addition, in procedure-oriented languages such as 
SDL, and in compilers in particular, programs are written in M passes M 
(this is also true for the MCP, to some extent: the collection of 
procedures to process control cards, for example, or the procedures to 
process I/O error ...conditions). In other words, code which is executed 
together in time is gathered into segments, and segments which are 
executed together in time are gathered together into pages. Thus, SDL 
code addresses specify (either explicitly, or implicitly) a triple that 
is used to generate an actual memory address if the segment is present, 
or a disk address if the segment is missing from memory. 

Code addresses in the SDL machine actually appear as pairs, triplets, 
or quadruplets (Figure 6). 

The Type field indicates the presence or absence of the Segment Number 
field and of the Page Number field, as well as the size of the Displace- 
ment field. The Page Number is the entry in the master Segment Dictionary 
used to find the minor Segment Dictionary to be used (if the minor Segment 



Dictionary is not present, then an interrupt is generated). The Segment 
Number is used to locate the entry in the minor Segment Dictionary which 
gives the location of the desired segment (if the segment is not 
present, then an interrupt is generated). The Displacement gives the 
relative .offset into the segment of the instruction being referenced. 

30 
This encoding allows the SDL machine to directly address 2 bits of 

code. This yields a 38.47. savings in space for the SDL machine when 
compared to a byte-oriented machine with equal addressing capability 
(see Wilner, 1972b). 



E. Data Addressing 

SDL data addresses are two-part addresses, the first part specifying 
'the lexic level of declaration of the data item, and the second part 
specifying the occurrence number of the data item within that lexic 
level. The data addresses do not contain memory addresses: this is 
the second condition that is necessary for re-entrancy. It also allows 
SDL procedures to be automatically recursive, and is part of the up- 
level addressing scheme. 

SDL data addresses are three-part addresses (see Figure 7). The Type 
field specifies the size (and type of contents) of the two following 
fields. The lexic level field indicates which entry of Display to use 
to subscript into the Name Stack. The occurrence number field is the 
number of 48-bit descriptors to offset to find the indicated descriptor. 
If Display and the Name Stack are considered as arrays, and V(LL,ON) 
is the address represented by a Type, Lexic Level, Occurrence Number 
triple, then 

V(LL,ON)=NAME.STACK(DISPLAY(LL)+ON) 
represents the formula used to calculate an address in the Name Stack. 



F. Descriptor Construction Operators 

As a procedure (lexic level) is entered, the local data for that lexic 
level is created by entering onto the Name Stack the descriptors for 
the local data. The descriptors are constructed with operators. 

Rather than carry the -descriptors intact in the code or somewhere else 
in memory, they are carried, in .an encoded form, in-line behind the 
operators which describe how the address field of the descriptor is to 
be derived. The in-line descriptor format and the Construct Descriptor 
Operators and their arguments are shown in Figure 8a. * The formulae for 
descriptor address calculations are shown in Figure 8b. 

The action of each of the operators is as follows: 

Construct Descriptor Base Zero (CDBZ): A descriptor is put on the 
Name Stack with an address of zero. 

Construct Descriptor Local Data (CDLD): The number of descriptors 
specified are constructed using the current value of the 
Value Stack Pointer as the address. The Value Stack Pointer 
is kept current as each descriptor is put on the Name Stack 
by adding to the Value Stack Pointer the length of the data 
item described. 

Construct Descriptor From Previous (CDPR), Construct Descriptor 

From Previous and Add (CDAD), Construct Descriptor From Previous 
and Multiply (CDMP): The number of descriptors specified are 
constructed using the following formulae to calculate the 
addresses: 



CDPR: A'=A+F 
CDAD: A'=A+F+L 
CDMP: A'=A+F+L+(E-l)xLB 
where 

A 1 is the new address part 

ft > ' * . 

A is the address part of the previous entry in the Name 

F is the in-line filler value if present 

L is the length part of the previous entry on the Name 

Stack 
E is the number-of-entries part of the previous entry on 

the Name Stack 
LB is the length-between part of the previous entry on 
the Name Stack 
Note that CDMP assumes that the previous entry on the Name Stack 
is an array descriptor. 
Construct Descriptor Lexic Level (CDLL): A descriptor is constructed 
on the Name Stack' which. has. as its address part the address 
of the value described by the descriptor specified by the 
LL, ON part. 
These 6 operators are sufficient to construct all the descriptors 
required by all possible combinations of arrays, structures, and filler 
as described in II-C. 



G. Handling of Control Statements 

SDL's sophisticated segmentation allows segment changes to appear 
Virtually anywhere within SDL programs. This non-sequential program 
flow combined with the lack of a GO TO in the S-machine created some 
interesting complexities. In an attempt to handle all of these com- 
plexities in a uniform manner, very heavy use was made of the Program 
Pointer Stack. All of the control statement operators (except Cycle) 
cause insertion or removal of entries from this stack. All of these 
operators can or do affect the next instruction address. The format 
of the control statement operators is given in Figure 9. A description 
of the operators follows. 

Call (CALL): The Call operator is used to enter DO and DO FOREVER 

groups when these do not follow THEN and ELSE, and are not part of 
a CASE. The argument of the Call is the code address of the DO 
or DO FOREVER. Execution of the Call causes the current program 
address to be pushed onto the Program Pointer Stack, and the next 
instruction to be executed from the address indicated by the 

argument . 
If-Then (IFTH): The If-Then operator is (as might be expected) used 
to handle the IF-THEN statement. The operator examines the low- 
order bit of the value described by the descriptor on the top of 
the Evaluation Stack. If this bit is 1 then the current program 
address is pushed onto the Program Pointer Stack, and the next 
instruction to be executed is taken from the address indicated by 
the (code address) argument. 



If-Then-Else (IFEL): The If-Then-Else operator is used to handle 

the IF-THEN-ELSE statement. The current program address is pushed 
onto the Program Pointer .Stack. If the low-order bit of the value 
described by the descriptor on the top of the Evaluation Stack is 
1, then the next instruction address is indicated 1/ the first 
code address following the operator; otherwise, the next instruction 
address is indicated by the second code address following the 
operator. 

Case (CASE): The Case operator is used for CASE statements. The value 
described by the descriptor on the top of the Evaluation Stack is 
compared to the number, N, of code addresses following the operator: 
if the value is greater than X or equal to N, then an error occurrs; 
otherwise, the value is used to subscript into the code addresses. 
If the code address" selected is null, then the operator is "termi- 
nated and the next instruction is executed; otherwise, the current 
program address is pushed onto the Program Pointer Stack and the 
selected code address is used to obtain the next instruction 
address. 

Undo (UNDO): UNDO statements are handled by the Undo operator. Since 
more than one level of nesting may be undone by any given UNDO 
statement, the number of levels to undo is contained in the instruc- 
tion. The number of levels specified is popped from the Program 
Pointer Stack and the last one popped is used as the address of 
the next instruction. 

Undo Conditionally (UNDC): The statement 
IF- <fconditior^> THEN UNDO; 
is one that causes needless manipulation of the Program Pointer 



Stack if handled with the If-Then and Undo operators. Consequently, 
a special operator was devised which is no more than the amalgamation 
of these operators: if the low-order bit of the value described 
by the descriptor on the top of the Evaluation Stack is 1, then 
an .Undo operation is performed; otherwise, the next instruction is 
executed. 
Cycle (CYCL): DO FOREVER loops are handled by the Cycle operator. Since 
DO (and DO FOREVER) groups are required to terminate in the segment 
in which they began, it is sufficient to subtract some amount from 
the current program address. The amount to be subtracted is con- 
tained in the field following the Cycle operator. 

It might be noted that, because some of these operators contain code 
addresses, it is possible to obtain some, nice optimizations. In parti- 
cular, if UTP is the name of an untyped procedure which has no parameters, 
then the following cases may be optimized by merely using the address 
of the procedure as part of the instruction; 

IF -(condition) THEN UTP; 

IF <condition> THEN,...; ELSE UTP; 

CASE ^expression); 



UTP; 



END CASE; 



H. Procedure Entrance and Exit 

Procedure entrance and. exit are a form of control statement execution, 
'but are more complex than those statements described in IV-G, since the 
Control Stack and the Display may also be affected. 

Procedure entrance and exit always affects the Program Pointer Stack 
and affect the Control Stack and Display when there is local data and/or 
parameters. 

A call to a procedure with no local data and no parameters requires 
only the Call operator (see IV-G). A call to a procedure with local 
data but no parameters requires a Call operator followed by a Mark 
Stack and Update operator executed inside the procedure. A procedure 
with parameters and with or without local data requires a Mark Stack 
operator, followed by the operators to put the actual parameters on the 
Evaluation Stack, followed by a Call operator. Inside the procedure, 
a Construct Descriptor Formal operator is executed. (See Figure 10). 

The Call, Mark Stack, and Mark Stack and Update operators will be 
described here; the Construct Descriptor Formal operator will be 
described in section IV-I. 

Call (CALL): The argument of the Call is the code address of the pro- 
cedure to be entered. Execution of the Call causes the current 
program address to be pushed onto the Program Pointer Stack, and 
the next instruction to be executed from the address indicated by 
the argument. 



Mark Stack (MKS): The Mark Stack operator causes construction of an 
entry on the top of the Control Stack. This entry contains the 
current values of the Name and Value Stack Pointers. The Exited 
Lexic Level field of the entry is set to the value of the current 
lexic level, and the Entered Lexic Level field is set to zero. 

Mark Stack and Update (MKU): The Mark Stack and Update operator has 
as an argument the lexic level of the procedure being entered. 
This operator causes construction of an entry on the top of the 
Control Stack. The entry contains the current values of the Name 
and Value Stack Pointers. The Exited Lexic Level field of the 
entry is set to the value of the current lexic level, and the 
Entered Lexic Level field is set to the value specified as the 
operator argument. The Display Stack entry for the specified 
lexic level is set to the current value of the Name Stack Pointer. 
The current lexic level is changed to the specified lexic level. 

All procedure exits are done with the RETURN statement; however, the 
operator generated depends upon whether or not the procedure contains 
local data or parameters, and upon whether or not the procedure is typed 

If the procedure contains no local data and has no parameters (and 
therefore did not change the Control Stack upon entrance), then an Undo 
operator is used to effect the return. If there is either local data 
or parameters and the procedure is not typed, then an Exit operator is 
used. If there is either local data or parameters and the procedure 
is typed, then a Return operator is used. (See Figure 10.) 



The Undo operator. was described in IV-G. The Exit operator will be 
described here, and the Return operator will be described in section IV- I. 

Exit (EXIT): The Name and Value Stack Pointers are set to the values 
obtained from the top entry of the Control Stack. The Display 
entry pointed to by the current lexic level is restored to the 
Name Stack value obtained from the first (proceeding from top to 
bottom) Control Stack entry, if any, having an Entered Lexic Level 
field equal to the current lexic level (unless a prior or the present 
entry has a zero Exited Lexic Level field). The Exited Lexic Level 
field is used to set the current lexic level, and the top entry is 
popped from the Control Stack. The number of levels specified is 
popped from the Program Pointer Stack and the last one popped is 
used as the address of the next instruction. 



I. Parameter Passing — Returning of Values 

The formal parameter statement assigns a type (and length) to each of 
the formal parameters. The SDL programmer has the option of having the 
SDL machine (interpreter) verify that the actual parameter matches the 
formal parameter. Since this check is time-comsuming, it is typically 
not performed once a program has been debugged. The consistency check 
is. performed by the Construct Descriptor Formal operator (see Figure 11). 
When the check is to be done, this operator has, as its arguments, 
"descriptor templates" for each of the formal parameters. The description 
of this operator follows: 

Construct Descriptor Formal (CDFM): The Construct Descriptor 
Formal operator assumes that a Mark Stack operator was executed 
before the actual parameters were placed on the Evaluation Stack. 
The current lexic level is changed to the lexic level specified by 
the operator. The specified lexic level is also put into the 
Entered Lexic Level field of the top entry in the Control Stack. 
The Display Stack entry for the specified lexic level is set to 
the current value of the Name Stack Pointer. The current lexic 
level is set to the specified lexic level. The number of descriptors 
specified is constructed on the Name Stack using the in-line des- 
criptor information plus the corresponding descriptor information 
on the Evaluation Stack. The type and length fields are compared 
for consistency between corresponding descriptors on the Evaluation 
and Name, Stacks. The Evaluation Stack is cut back after construction 
of the descriptors; the Value Stack is not. 



The values returned by typed procedures in SDL should agree in type 
and length with the formal type of the procedure itself. The SDL 
programmer again has the option of specifying whether or not this con- 
sistency check is performed by the interpreter. If this check is to 
be performed then the Return operator contains a descriptor template in- 
line following the operator. 

Return (RTRN): The Return is the same as the Exit operator prior to 

popping entries off the Program Pointer Stack. At this point, the 
data descriptor on the Evaluation Stack is compared to the in-line 
descriptor for consistency. If the data is on the Value Stack, 
then after cutting back the Value Stack, the data is moved to the 
new top of the Value Stack. The number of levels specified is 
popped from the Program Pointer Stack and the last one popped is 
used as the address of the next instruction. 



J. Special Operators 

In order to illustrate further the complexity and flexibility possible 
with a machine such as the B1700, several of the special operators 
will also be described. 

Search Li nked List 

The Search Linked List operator is used principally by the MCP to 
allocate memory space. This operator compares a value with a list of 
linked structures, searching' for the indicated relationship or the end 
of the list. The argument specifies the compare type: less, less or 
equal, equal, not equal, greater or equal, greater. There are four 
descriptors on the Evaluation Stack. The descriptors represent: 

1) Link Index: the relative offset in the structure, and the size^ 
of the field which contains the address of the next structure 
to be examined 

2) Compare Variable: the variable to be compared to the linked 
structure 

3) Argument' Index: the relative offset in the structure, and the 
size^ of the field to which Compare Variable is to be compared 

4) Record Address: the address of the first structure to examine 

The operator returns the address of the structure whos.e compare field 
was in the desired relationship to the Compare Variable, or it returns 
an indicator that there were no structures in the desired relationship. 

Reinstate 

The Reinstate operator is the operator used by the MCP to reinstate a 



user program. The descriptor on the top of the Evaluation Stack is 
assumed to describe a field in the Run Structure of the program to be 
reinstated. The reinstating program's M-machine state is stored in 
its own Run Structure (each program currently executing has a Run 
Structure which contains the program's execution attributes). The 
address of the reinstating program's Run Structure is stored in the 
reinstated program's Run Structure. The descriptor at the top of the 
Evaluation Stack is removed. The address field of this descriptor 
addresses the Run Structure of the program which is then reinstated. 

Next Token 

The Next Token operator is used by compilers to scan source images. 
The first argument is the data address of a descriptor which describes 
the first character to be examined. It is assumed that this character 
is non-blank. The second argument is a "separator" character (such as 
"-" in COBOL). The third argument is the "numeric-to-alpha indicator". 

If the character described by the first argument is a special character, 
then the operator is exited with a descriptor on the top of the Evalu- 
ation Stack which describes this character, and with the descriptor 
described by the first argument advanced to point to the next character 
in the source image. 

If numeric- to- alpha indicator is 1 then the stopper is set to "A"; other- 
wise, if the first character is numeric then the stopper is set to "0"; 
otherwise, the stopper is set to "A". Characters are sequentially 
compared to the stopper until one is found which is less than the stopper 



and not equal to the separator. The operator then exits with a descriptor 
on the top of the Evaluation Stack which describes the token just found, 
and with the descriptor described by the first argument advanced 'to 
point to the next character in the source image. (The EBCDIC collating 
sequence is assumed). 



V. Conclusion 

In this brief description of the B1700 Software Development Language 
(SDL), and its underlying S-machine, I have attempted to give some 
indication of the flavor of SDL but, more importantly, to illustrate 
the extreme flexibility and suitability of the B1700 for the tasks for 
which it was designed: the writing of (language) interpreters and 
emulators. We who have used SDL feel that it is well-suited for the 
type of programming for which it was designed. We could not agree more 
with Saltzer et al (MIT, 1970) that one of our best decisions was to 
program the operating system in a higher-level language. However, 
the degree of success of the software depends very heavily upon the 
suitability of the hardware to the software and to the language in which 
the software is written. The Burroughs B1700, by its very nature, has 
proven to be quite suitable to the tasks to which it has been assigned. 
It should be pointed out, that because all of the software for the B1700 
has been written in a higher-level language, all of it (including the 
MCP) is theoretically transportable to any other system which has soft 
interpretation (of the flexibility of the B1700). 
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VII. APPENDIX I: 



SDL S- OPERATORS 



RELATIONAL OPERATORS 

NAME 

EQUAL TO 

LESS THAN 

LESS THAN OR EQUAL TO • 

GREATER THAN 

GREATER THAN OR EQUAL TO 

NOT EQUAL TO 



MNEMONIC 


OP CODE 


SIZE 


ARGUMENTS 


EQL 


6 






LSS 


10 






LEQ 


10 






GTR 


10 






GEQ' 


10 






NEQ 


6 







ARITHMETIC OPERATORS 

NAME 

ADD 

SUBTRACT 

MULTIPLY 

DIVIDE 

MODULO 

REVERSE SUBTRACT 

REVERSE DIVIDE 

REVERSE MODULO 

NEGATE 

CONVERT TO DECIMAL 

CONVERT TO BINARY 



MNEMONIC 


OP 


CODE SIZE 


ARGUMENTS 


ADD 




6 




SUB 




6 




MUL 




10 




DIV 




10 




MOD 




10 




RSUB 




10 




RDIV 




10 




RMOD 




10 




NEG 




10 




DEC 




10 




BIN 




10 





LOGICAL OPERATORS 

NAME 

AND 
OR 

EXCLUSIVE- OR 
NOT 



MNEMONIC 

AND 
OR 
XOR 
NOT 



OP CODE SIZE 

10 
10 
10 
10 



ARGUMENTS 



STRING OPERATORS 
NAME 

CONCATENATE 
SUBSTRING TWO 
SUBSTRING THREE 



MNEMONIC 

CAT 
SS2 
SS3 



OP CODE SIZE 

6 

10 

6 



ARGUMENTS 



LOAD OPERATORS 



SDL S- OPERATORS (CONTINUED) 



NAME 

MAKE DESCRIPTOR 
VALUE DESCRIPTOR 
DESCRIPTOR 

NEXT OR PREVIOUS ITEM 
•LOAD VALUE 
LOAD ADDRESS 
ARRAY LOAD VALUE 
ARRAY LOAD ADDRESS 
INDEXED LOAD VALUE 
INDEXED LOAD ADDRESS 
LOAD LITERAL 
LOAD 10-BIT LITERAL 
LOAD LITERAL ZERO 
LOAD LITERAL ONE 



MNEMONIC 


OP CODE SIZE 


ARGUMENTS 


MDSC 


10 




VDSC 


10 - 




DESC 


6 


DA 


NPIT 


10 


V,DA 


L 


6 


DA 


LA 


4 


DA 


AL 


10 


DA 


" ALA 


6 


DA 


IL 


10 


DA 


ILA 


4 


DA 


LIT 


4 


D, LITERAL 


LITN 


4 


LITERAL 


ZOT 


4 




ONE 


4 





STACK OPERATORS 

NAME 



MNEMONIC 



OP CODE SIZE 



ARGUMENTS 



BUMP VALUE STACK POINTER 

DUPLICATE 

DELETE 

EXCHANGE 

FORCE VALUE STACK 



BVSP 

DUP 

DEL 

XCH 

FVS 



10 
6 

10 
6 
6 



STORE OPERATORS 



NAME 


MNEMONIC 


OP CODE SIZE 


ARGUMENTS 


STORE DESTRUCTIVE 


STOD 


4 




STORE NON-DESTRUCTIVE LEFT 


SNDL 


6 




STORE NON-DESTRUCTIVE RIGHT 


SNDR 


10 




CONSTRUCT DESCRIPTOR OPERATORS 








NAME 


MNEMONIC 


OP CODE SIZE . 


ARGUMENTS 



CONSTRUCT DES. BASE ZERO 

CONSTRUCT DES. LOCAL DATA 

CONSTRUCT DES. FORMAL 

CONSTRUCT DES. FORMAL- V2 



CDBZ 
CDLD 
CDFM 

cdfm: 



10 

6 

10 

10 



N,D1,...,DN 

LL,E 

LL,E,D1,...,DN 



SDL S- OPERATORS (CONTINUED) 



CONSTRUCT DESCRIPTOR OPERATORS (CONTINUED) 
NAME MNEMONIC 



CONSTRUCT DES. 
CONSTRUCT DES. 
CONSTRUCT DES. 

MULTIPLY 
CONSTRUCT DES. 



FROM PREV. 
FROM PREV. & 
FROM PREV. & 

LEXIC LEVEL 



ADD 



CDPR 
CD AD 

CDMP 
CDLL 



OP CODE SIZE 

6 
6" 

10 
10 



ARGUMENTS 



N,D1,...,DN 
N,D1,...,DN 

N,D1,...,DN 
DA,D 



PROCEDURE OPERATORS 
NAME 

CALL 

IF THEN 

IF THEN ELSE 

CASE 

UNDO 

UNDO CONDITIONALLY 

RETURN- VI 

RETURN- V2 

EXIT 

CYCLE 

MARK STACK 

MARK AND UPDATE 



MNEMONIC 


OP. CODE SIZE 


ARGUMENTS 


CALL 


4 


CA 


IFTH 


4 


CA 


ITEL 


6 


TYPE,CA,CA 


CASE 


10 


N, TYPE, CA1,..., CAN 


UNDO 


4 


" L 


UNDC 


10 


L 


RTRN 


10 


L 


RTRN: 


10 


L,D 


EXIT 


6 


L 


CYCL 


6 . 


DISPLACEMENT 


MKS 


6 




MKU 


10 


LL 



MISCELLANEOUS OPERATORS 

NAME 

SWAP 

INTERRUPT STATUS 

FETCH 

DISPATCH 

HALT 

READ CASSETTE 

LENGTH 

LOAD SPECIAL 

CLEAR 

COMMUNICATE 

REINSTATE 

FETCH CMP 

ADDRESS 

SAVE STATE 

HARDWARE MONITOR 

OVERLAY 

PROFILE 

SEARCH LINKED LSSf 



MNEMONIC 


OP CODE SIZE 


ARGUMENTS 


SWAP 


10 




IIS 


10 




FECH 


10 




DISP 


10 




HALT 


10 




RDCS 


10 




LENG 


10 




LSP 


10 


V 


CLR 


10 




COMM 


10 




REIN 


10 




FCMP 


10 




ADDR 


10 




SVST 


10 




HMON 


10 




OVLY 


10 




PRFL 


10 


N 


SLL 


10 


V 
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SDL MEMORY STRUCTURE 



Value Stack 
. __ _ 

Name Stack 



~> 



Display 



<r~ Base Register 



Control Stack 
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4, 



> Program Static Memory 



f- 



Program Pointer Stack 

Paged Array 
pages and 
page tables 



i 



> 
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J 



Program Dynamic Memory 



^__ 



Limit Register 



FIGURE 1. 



U4m/juj wi-.ri.Y_ii 



DISPLAY 
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FIGURE 2a. 



SDL STACK INTER-RELATIONSHIP 



Display 



Name 
Stack 



Value 
Stack 



1 2 



r t *>*^ * " * 




Control Stack Entry 1 describes a currently inactive lexic level. 



FIGURE 2b. 



SDL OPCODE STRUCTURE 



4 bits 



thru 9 



4 bits 2 bit 



10 thru 14 



thru 3 



4 bits 6 bits 



15 



thru 64 



FIGURE 3. 



MCP OPERATOR ENCODING 



ENCODING METHOD 



TOTAL BITS FOR 
MCP'S OPCODES 



UTILIZATION 
IMPROVEMENT 



DECODING 
PENALTY 



HUFFMAN 



172,346 



437. 



17.2% 



SDL 4,6,10 



184,966 



397. 



2.67. 



8-BIT FIELD 



301,248 



07. 



0.07. 



FIGURE 4a. 



Eight-bit field 




.05 1.10 

Decoding time 



1.15 1.17 



1.20 



FIGURE 4b. 






SDL DESCRIPTOR FORMATS 



SIMPLE DESCRIPTOR: 



TYPE 


LENGTH 


ADDRESS OR DATA 



16 



24 



ARRAY DESCRIPTOR: 



TYPE 


LENGTH OF ELEMENT 


ADDRESS OF FIRST ELEMENT 


PAGE SUB- 
SCRIPT SIZE 

- -,- Lll 


LENGTH BETWEEN 
ELEMENTS 


NUMBER OF ELEMENTS 



TYPE FIELD: 



16 



24 



NOT USED 
1 FOR PAGED ARRAY 



DATA TYPE: BIT(OO), FIXED(Ol), 
CHARACTER (10), VARYING(ll) 

1 IF LENGTH OF ELEMENT = LENGTH BETWEEN 
ELEMENTS (CONTIGUOUS ARRAY) 



1 IF ARRAY DESCRIPTOR 



1: NON SELF-RELATIVE 

0: SELF-RELATIVE (DATA ITEM IS IN ADDRESS FIELD) 



NAME- VALUE BIT 



FIGURE 5, 



SDL CODE ADDRESS 



TYPE 



SEGMENT NO. 



PAGE NO. 



OR 6 



DISPLACEMENT 



OR 4 12,16,OR20 



TYPE 


SEGMENT NO. 


PAGE NO. 


DISPLACEMENT 


TOTAL BITS 


000 


CURRENT 


CURRENT 


12 BITS 


15 


001 


CURRENT 


CURRENT 


16 BITS 


19 


010 


6 BITS 


CURRENT 


12 BITS 


21 


Oil 


6 BITS 


CURRENT 


16 BITS 


25 


100 


6 BITS 


4 BITS 


12 BITS 


25 


101 


6 BITS 


• 4 BITS 


16 BITS 


29 


110 


6 BITS 


4 BITS 


20 BITS 


33 


111 


- 


- 


- 


3 



FIGURE 6. 



SDL DATA ADDRESSES 



TYPE 



LEXIC LEVEL 



OCCURRENCE NO. 



1 OR 4 



5 OR 10 



YPE 


LEXIC LEVEL 


OCCURRENCE NO. 


TOTAL BITS 


00 


A BITS 


10 BITS 


16 


01 


4 BITS 


5 BITS 


11 


10 


1 BIT * 


10 BITS 


13 


11 


1 BIT * 


5 BITS 


8 



* 0: LEXIC LEVEL 

1: CURRENT LEXIC LEVEL 



FIGURE 7. 



SDL CONSTRUCT DESCRIPTOR OPERATORS 



IN-LINE DESCRIPTOR FORMAT: 



TYPE 



LENGTH 



FILLER 



LENGTH BETWEEN 
ELEMENTS 



PAGE SUBSCRIPT 
SIZE 



NUMBER OF 
ELEMENTS 



8 6 OR 17 0,6, OR 0,6, OR 17 
17 



OR 8 



0, 6, 17 



6- OR 17-BIT FIELDS: 



5 BITS 



16 BITS 



CONSTRUCT DESCRIPTOR OPERATORS: 

OPERATOR 

BASE ZERO 

LOCAL DATA 

FROM PREVIOUS 

FROM PREVIOUS AND ADD 

FROM PREVIOUS AND MULTIPLY 

LEXIC LEVEL 



MNEMONIC 


OPCODE 


ARGUMENTS 


CDBZ 


1111 10 0100 


D 


CDLD 


1110 00 


N,D1,...,DN 


CDPR 


1110 10" 


N,D1,...,DN 


CDAD 


1110 01 


N,D1,...,DN 


CDMP 


1111 10 0101 


N,D1,. # .,DN 


CDLL 


1111 10 0011 


DA,D 



WHERE D AND DI ARE IN-LINE DESCRIPTORS, AND DA IS A DATA ADDRESS 
(TYPE, LEXIC LEVEL, OCCURRENCE NUMBER) 



FIGURE 8a, 



SDL CONSTRUCT DESCRIPTOR ADDRESS CALCULATIONS 



OPERATOR 

CDBZ 
CDLD 
CDPR 
CDAD 
CDMP 
CDLL 



ADDRESS 

A' = 

A» = V 

A» = A + F 

A* = A + F + L 

A* = A + F + L + (E-l) x LB 

A 1 = ADDRESS (DA) + F 



WHERE 



A' IS THE NEW ADDRESS PART 

V IS THE VALUE 'STACK POINTER 

A IS THE ADDRESS PART OF THE PREVIOUS ENTRY IN THE 

NAME STACK 
F IS THE IN-LINE FILLER VALUE, IF PRESENT 
L IS THE LENGTH OF THE PREVIOUS ENTRY ON THE 

NAME STACK 
E IS THE NUMBER-OF-ENTRIES PART OF THE PREVIOUS 

ENTRY ON THE NAME STACK 
LB IS THE LENGTH-BETWEEN-ENTRIES PART OF THE PREVIOUS 

ENTRY ON THE NAME STACK 
DA IS THE IN-LINE DATA ADDRESS 



FIGURE 8b. 



SDL CONTROL STATEMENT OPERATORS 



OPERATOR 


MNEMONIC 


OPCODE 




ARGUMENTS 




CALL 


CALL 


0111 






CA 




IF-THEN 


IFTH 


1001 






CA 




IF-THEN-ELSE 


IFEL 


1101 


10 




AT,CA,CA 




CASE 


CASE 


1111 


01 


0100 


N,AT,CA1,.. 


.,CAN 


UNDO 


UNDO 


1000 






L 




UNDO CONDITIONALLY 


UNDC 


1111 


01 


0011 


L 




CYCLE 


CYCL 


1110 


11 




D 





WHERE 



CA IS A CODE ADDRESS (TYPE, SEGMENT NUMBER, PAGE 

NUMBER, DISPLACEMENT) 
AT IS THE CODE ADDRESS TYPE , 
N IS THE NUMBER OF CODE ADDRESSES 
L IS THE NUMBER OF LEVELS TO UNDO 
D IS THE NUMBER OF BITS OF DISPLACEMENT 



FIGURE 9. 



SDL PROCEDURE ENTRANCE AND EXIT OPERATORS 



OPERATOR 


MNEMONIC 


OPCODE 


ARGUMENTS 


MARK STACK 


MKS 


1011 11 




MARK STACK AND UPDATE 


MKU 


1111 01 1111 


LL 


CALL 


CALL 


0111 


CA 


EXIT 


EXIT 


1101 11 


L 


UNDO 


UNDO 


1000 


L 


RETURN 


RTRN 


1111 01 0101 


L,D 



WHERE 



LL IS THE ENTERED LEXIC LEVEL 

CA IS A CODE ADDRESS 

L IS THE NUMBER OF LEVELS TO REMOVE FROM THE 

PROGRAM POINTER STACK 
D IS A TYPE, LENGTH PAIR 



FIGURE 10. 



SDL CONSTRUCT DESCRIPTOR FORMAL 



OPERATOR 



MNEMONIC OPCODE ARGUMENTS 



CONSTRUCT DESCRIPTOR FORMAL ' CDFM 1111 01 0001 L,E,Dl, . . . ,DN 



WHERE 



L IS THE ENTERED LEXIC LEVEL 

E IS. THE NUMBER OF 48-BIT ENTRIES ON THE EVALUATION 

STACK 
DI ARE IN-LINE DESCRIPTOR TEMPLATES OF THE FORM: 



TYPE 


LENGTH 


NUMBER OF 
ENTRIES 



0,16 0,16 



TYPE: 





1 IF ARRAY 



1 IF LENGTH VARYING 



1 IF ARRAY BOUND VARYING 



DATA TYPEi BIT(QO), FIXED(Ol) 
CHARACTER (10), VARYING(ll) 



FIGURE 11. 



